谈架构
关于架构
架构是一个动词，还是一个名词？可以组合的词汇有：架构设计、架构师， 我的观点，架构是动态的，演进的。
词典：架构，jià gòu。人们对一个结构内的元素及元素间关系的一种主观映射的产物。也可指构筑，建造。
同时架构亦可以理解为建造的过程。
架构是一种思维模式。架构师是一个title。为什么说架构是一种思维模式呢，小到一个模块，大到一个平台，都是一样样的。
有人说软件架构的作用包括
软件架构能够满足系统的品质
架构设计使受益人达成一致的目标
架构设计能够支持计划编制过程
架构设计对系统开发的指导性
架构设计能够有效地管理复杂性
架构设计为复用奠定了基础
架构设计能够降低维护费用
架构设计能够支持冲突分析
这些表述看起来都是对的，但是如何系统化的看这8个维度呢？
项目或者产品研发过程中有系统分析文档，概要设计等，而这些文档都是有模板可以遵循，模板这个东西很奇怪，赞的地方是依照葫芦画瓢不至于太难看，不好的地方是如何体系多个目标或者多维度诉求的达成？
立刚老师上次有精彩的分享，关于好的应用架构，抄录要点如下
好的应用系统特点
满足业务功能
用户体验好
稳定可靠
维护简单
扩展性强
完全满足业务需求做不出好系统
业务需求是理想、技术是现实，理想是我们希望像鸟儿一样自由地飞出银河系，现实就是我们刚能踏上月球，还上不了火星，还必须借助于笨重的宇航服、宇宙飞船。
纯靠技术做不出好的业务系统
以减少系统功能降低用户体验为代价的高可用、高性能、高并发等貌似很NB的系统是得不到赞赏的。
一个好的业务系统一定是技术与业务的完美平衡
我们在谈架构是什么，理想中的架构该是多么美好，但是具体要如何做呢？
市面上有关架构的书籍有： 面向模式的软件架构、程序员必读之软件架构、企业应用架构模式、 一线架构师实践指南等等。有一些是方法论，有些是案例集、有些讲架构师的素质。
基于我从业的所见所闻所感，我提出的一个明确观点是以终为始的架构设计。
什么叫以终为始呢，就是满足或者引导客户价值的挖掘和表达。
上图是一个非常著名的图，用户描述的需求和实际实现的差异，架构设计作为统领全局的方法体系，自然要贯彻始终的最好需求的真实反映、衡量标准的提炼（SLA）、端到端的运行处理、业务运营能力来支撑目标架构的实现，从而支撑当下需求和为远期需求发展做好可能的准备。
请容许我用黄金圈理论就是why-what-how的线索来叙述一下，关于why-为什么要做架构。
为什么要做架构设计
按黄金圈理论，不妨先来回答一下why的问题。我认为架构就如同一张蓝图，没有图纸很难建造房屋。
如果说设计师给你的效果图=UI设计的话
那么建筑工人建造的就是设计的骨架了[分层、部署]
而合适的架构可以见微知著，适应变化，在快速规模化效应到来时较好的解决客户问题。比如如下图的2个例子，帆船发展到船身的扩大，内部设施的变化；
传统的电商模式，营销方式是打折、满减、包邮、满返；而线下业务比如肯德基又衍生了第二件半价，第三件又如何！
总结一下，tips：
# 1没有设计师的蓝图无法建造房屋
# 2 快速规模化、适应变化、解决客户问题
如何做架构设计
把我的观点切分了3个维度，why-how-what；11个观点。则how涵盖范围为#3-#8。
# 3 以终为始，不忘初心
初心是什么，就是用户的本质需求。用户想要什么就给什么未必是本质需求，比如张三问你要面包，你无法提供，但是他的本质可能是因为他饿了。
如上图，不论系统如何组织，用户最关心的是响应时间(Response Time)，和展示金额对不对。所以在一开始设计的时候要考虑如何取得用户的2个关注要素，正确性和体验。是否考虑链路级的监控，链路级的关键数据校验，规则如果分散到多个系统，如何检查整体组合命中的情况等，都在考虑之列；链路上每个系统的容量和响应时间等。
# 4 PMC框架
什么是PMC框架呢？P>platform\M>merchant\C>customer
平台型的产品都有这3端的考量。
比如，天猫、uber、O2O的app
滴滴或者uber解决出行的问题，电商解决网上购买商品的问题。平台的本质设计是符合用户侧、商户侧、平台侧的3端诉求的。比如电商的IM解决信息沟通，客服解决售后，还有其它方式解决可能的作弊，交易、安全、评价体系等一系列的问题。uber也是基于交易，乘客付款给司机，但是对于用户而言是更快更省的叫到车，司机的信用评价沿用了星级评价，投诉等保障措施，但对于基于地理位置的撮合（用户的地点，划定一个圈寻找可以承载他的车包括允许共享座位的车）是其核心，也是uber孵化出dispatch模块的原因。
有意思的事情发生了，uber老板一觉醒来发现他创造的不仅仅是一家出行公司。
司机和车只是它的资源，供应方（supply）可以是一家蛋糕店、鲜花店或者是西湖的休闲船只管理中心，那么它那些能力可以复用：
1、调度能力
2、用户呼叫的界面、策略
3、地理位置处理
4、交易事后处理等
大部分变化在于运送的物品（属性）以及一些附属需求，而这些都是可以通过良好的平台设计+可扩展的新市场产品特性来完成。
#5 架构非单一视角、单一层次
架构的多层次多视角有助于厘清本质，对问题域更好求解
有同学可能讲了，多个视角有什么用呢？
以一个第三方支付的应用为例，就有诸多的考量因素。比如风控、比如营销、比如签约（签约的顺畅度）等。
按业务执行、业务运营等视角又可以加以组合，组合有什么用呢，用来考量设计的要素（谁为谁服务）。
比如营销是业务运营板块，为了更好的业务执行的。uber的打折优惠也好，拼车免费也好，都是不影响主流程的，且为了进一步刺激消费；然而有的产品把营销活动设计的极其生硬，极其难用，相当于把一件大人的衣服穿到了一个小朋友身上。
再举一个例子，体验和服务，我在想存在一种可能的设计，比如新上一个产品，考虑可能带来的服务量（在线客服、热线客服、帮助等），当实际操作一定比例的时候，强烈预警产品应该优化，并能分析出优化之所在。可能一开始数据线拍的不准，但是不断训练和尝试，则能形成正循环。一个不恰当的KPI就是服务的目标是降低来电，减少二次来电，但产品不断野蛮生长，最后也就是一个然并卵的问题了。
ps：在百度，通过快速构建mvp然后通过舆情信息的收集不断优化产品迭代就是一种蛮有意思的尝试，业务运营一定要为业务执行（产品）服务。
#6 聚焦SLA
避免关注枝节遗忘全局
避免关注自身忘却出发点
前面阐述了以客户价值出发构建架构，同时考虑C（客户侧）、P（平台侧）、M（商户侧）的不同诉求。那么如何衡量这些成效达到了呢？
则需要清晰明确的设定SLA。12306经历了02年的阻塞、中间间或的宕机、到与黄牛（抢票软件等）斗智斗勇开启了杀伤力巨大的图片校验码而引发众多吐槽。那么12306对客户带来的价值是什么呢？首先要尽量多的人买到票（票的数量受制于运输能力），比较顺畅的拿到票（有人搞了几天也没抢到），公平性（开发抢票软件的浏览器是不是应该治理，还有哪些抢票的地下软件）。有专家说12306不要把图片校验码搞复杂，对抗黄牛不是他的主要职责。我认为只说对了一半呢，防作弊是它要做的事情，因为为了客户价值达成。当然有报道12306图片识别困难，则铁道部有回应，能买到票就不错了，则显得对价值的识别又low了，票终会卖完（这2年系统不宕了），票以什么方式卖完，大部分人购买的顺畅体验也是非常重要的。
插播素材来源
(http://star.news.sohu.com/20151209/n430421074.shtml )
新华社12月8日发表时评《12306验证码究竟打败了谁？ 》
文章说，面对消费者的质疑，铁路部门不及时回应群众关切，不作出解释，也不针对问题修改验证码设置，这种冷处理的确令人费解。铁路部门还需增强意识和技术手段，摒弃一家独大的“傲慢思维”，从改进验证码这种细节抓起，多麻烦自己、少难为群众，通过体制机制的创新，让群众出行更方便。
说了这些，大家不妨就梳理一下实现客户满意可以用的招，比如是不是搞预约，预约才有资格买票（且7*12小时分批），避免拥堵（非通知取票时段）你去刷也没用。再比如运行程序如何区分来的是普通用户还是刷单软件，采取不同的策略对待，这里肯定有不少事情可以做，而不是一图难天下。讲了12306，来看一个例子，以第三方支付为例。(很多图形均为示意，切莫细究图示模块内容完备性。)
业务运行（支付业务），涉及到用户下单、形成交易并支付等相关处理。而用户很关注我能不能快速把钱正确安全的付掉。为了求证付款正确性，他们也会习惯性在第一时间查询消费记录。对于商户而言，他们也有查询收支明细的诉求。可能有人问了解SLA要求，和具体设计存在哪些关联呢？
仍以上图为例，我们可以做一系列假设做恰当的预设计。
比如从系统运行角度看，如何度量用户SLA（体验的顺畅度，支付成功率）以及更多行为数据（用户在哪一步流失的，什么原因），从下单到完成支付的花费时间是多少等。要做这些，就需要全链路的监控，进而推之需要做统一的上下文，事件码来串联请求的链路（traceId 技术语义，业务语义则可能是userId）。再举一个例子，在数据量100万级可能通过buyerId 或者sellerId为查询条件分别满足按买家、商家不同的维度查询消费记录。当数据规模扩大之后，可能通过数据库表的拆分来做sharding。则涉及到key选取的问题，该问题就是比较典型的多维度查询问题。
#7 抽象、协作、扩展、复用
抽象、扩展人人都知道，但是如何识别本质并不做BDUF（Big design up front ）并不容易。以uber为例，uber定位已不仅仅是一家出行公司，利用其物流能力可以叫飞机，叫外卖，包括送花。
要知道uber也不是一天炼成的。 有文章披露，
旧系统是为专用客车运输所设计的，做了很多假设：每个车辆一个乘客，不适用 Uber Pool（拼车服务）。
运送人的想法深深嵌入到数据模型和接口里。这样限制了扩展到新的市场和产品上，比如运送食物和箱子。
最初的版本是按城市划分的。对于可扩展性而言是好的，因为每个城市可以独自运营。但当越来越多的城市加入，这变得越来越难以管理。城市有大有小，负载也不一样。
后来，他们重构了dispatch模块，让调度的接口不依赖具体的专用客车的领域而具备可扩展性，并通过微服务来做切分和管理。
因为尽在图中，所以什么都不用说了，1-6是可能存在的风险点，在设计上要考量。
#9 架构兼具组成和决策特点,架构之于架构是自包含关系
什么是架构有组成派、决策派之争，其实兼而有之。
#10 架构是演进出来的
架构是演进出来的，架构是动态的。下图为一个架构演进视图的举例说明。
11年我们有一个不太成功的示范，就是自信试水型业务一点会爆发，在产品层之下设计了一个基础层，做核心领域的沉淀，后来孵化了10+几个小产品，结果核心的2张表被玩坏了。完全烟囱型模型+plugin（or 工具黏合剂）可能更合适。
#11 无纯粹的非功能特性、区分功能\非功能，容易把后者当作增强性要素
可以看看下图为某平台的能力视图，容量，高可用能力，高性能都是和外部平台的要求匹配的
下图所示，所有大类都体现到功能上和部分用户感受上的。
tips：有人说我文章都看完了，但是我自己还是不知道如何干? 那就再帮帮你：
1、请度量你的产品对于用户、商户的SLA（接入效率、接入成本、用户体验、稳定性、应急处理能力等）
2、适当的时候考虑链路级业务监控视图
3、在系统链路调用上加上traceid这样的东东
4、考虑平台沉淀能力时考虑业务形态的扩展，比如uber只是一家解决出行的公司么？
5、在不同阶段采用不同架构，试水期说不定演烟囱型架构是最适合的，因为短期的价值是打一个点(业务上)，让自己活下去(平台方)！
6、非功能要素不是加分项，可能是主体价值体现点，比如商户需要一个批量导入接口，你提供了单笔处理接口，然并卵！
7、非功能要素融入到日常研发中，比如微软的同学分享office某个迭代性能慢了，就是P1级故障，其背后必须得有日常性能的回归环境才行。
写到最后，再次总结一下我的观点--3个层次、11个观点、一句话（以终为始）！
说明：本文风景配图来自师兄鲁韵涛、现居住于西雅图。
犒赏楼主请扫这个
关注请扫这个
文艺宅男的情怀
重要的事情说三遍，干货、干货、干货！